This is a significant breaking change, since it'll elevate previously ignored client session shutdown into full 'error' events that can crash things (as in the test changes here) among other issues, and it's also unpredictable: behaviour changing depending on write state means there's a race condition for everybody using this API (as noted in the test assertions here).

I think this approach could work, but it'll create problems in the short term anyway, and it seems like it adds complexity to the already confusing behaviour.

If we're going to break things to fix this, what if we fix this API more thoroughly as a cleaner major bump? Right now it's a mess:

• Behaviour for handling inbound cancellation depends on current dynamic write state, creating race conditions tied to connection write performance (today silent vs aborted, with this change error vs aborted).
• We don't fire any error event for the cancelled readable streams, and in fact they can end successfully! Today in all cases, or with this PR if writable is still open, if you're reading incoming data (client or server side) and not paying attention to 'aborted' you get an apparently complete stream with 'end' but actually truncated data (this is quite bad).
• The code references 'aborted' not erroring for HTTP/1 compat, but that makes no sense - AFAICT HTTP/1 does emit errors in equivalent cases, and the 'aborted' event has been deprecated there since Node 16 in favour of 'close'. I think H1 errors everywhere, except if the readable side has been fully consumed (i.e. just on a server where you're already read the whole request body - in that case it just emits 'close' with no error).

We definitely shouldn't emit 'end', and more consistent behaviour that's easier to predict & matches H1 would be nice. How about:

• We deprecate 'aborted' in H2, just like H1 (leaving the current behaviour for compat in the meantime?).
• Emit 'error' in all stream reset cases, except if the read-side is fully consumed (so no error for servers when client aborts a response) exactly like H1. No more risk of unexpected truncation, very clear when a stream is aborted uncleanly. If you didn't read everything, you get an error.

That would remove quite a few existing footguns here, leaving clear behaviour that's easier for everybody involved, and still close the original issue (just watch for error to consistently detect aborts). It's breaking, but not so much more than this PR, and it's more consistent with H1 and easier to understand. Needs some thought to confirm the details but I suspect the actually code change is a very similar size to the diff here. What do you think?